1. Technical Field
The subject matter herein applies to the field of computer networking, and more particularly to virtual private networking, network traffic tunnelling, and network traffic relaying.
2. Background of the Related Art
The Internet and the core Internet Protocol (“IP”) have become the ubiquitous format used by modern computer communication systems. The IP provides for network node addressing, IP datagram routing and delivery services. IP also forms a foundation for more elaborate communication services, such as those implemented by Transmission Control Protocol (“TCP”) and User Datagram Protocol (“UDP”). There are two major versions of IP, version 4 and version 6.
Internet nodes are identified by their IP network addresses. An IP network address is assigned to every node that participates in a network communication. This address has 32 bits and is commonly represented in a form of 4 octets separated by dots, for example 134.10.210.97. Every network packet sent over IP network includes the IP address of both the source and the destination. In addition, the packet may include both source and destination port numbers. Therefore, if the IP address identifies the computer on the network, the port identifies the particular program on the computer, for example, if the computer is running both a web server and email server, another computer may use port number 80 to direct a web packet to the web server program and port number 25 to direct email data to the email server program.
The Internet, currently comprised of billions of computers, has grown substantially in the last few years and the number of available IP addresses is diminishing, to the point where there is a shortage of available IP addresses. Faced with this shortage, organizations and individuals frequently opt to share a single Internet IP address between two or more computers. The technology to use this sharing is called Network Address Translation (“NAT”).
NAT allows multiple computers to share a single IP address. NAT operates by placing multiple computers on an internal network, assigning each computer a “private” IP address that is unique only within the internal network and configures them to access the Internet via a NAT device. The term NAT device, as used herein, refers to devices that dynamically modify the IP addresses found in IP packets sent by the computers in an internal network to make it appear that the internal computers are accessing the Internet from their shared address (and not the private IP address used in internal network). The NAT device may also modify port numbers if at some point more than one computer on the internal network uses the same local port number when sending packets to the Internet. In some other cases, the NAT device may also modify port numbers as dictated by internal NAT device logic. The NAT device stores or “remembers” how it modifies outgoing packets, so it is capable of uniquely identifying an internal computer when it receives a packet in response from the Internet. The NAT device then reverses the changes and forwards the packet to the appropriate computer on the internal network.
A default NAT configuration may cause a number of problems. For example, a computer using a NAT device (referred to as an “internal computer”) may be impossible to access from the outside (i.e. the rest of the Internet). This is because a computer on the Internet cannot address an internal computer unless it first receives some traffic from latter, meaning that internal computers cannot act as servers. Furthermore two computers, each using a different NAT device, cannot communicate with each other because neither will receive new connections from computers outside of their respective internal networks.
As computers with Internet connections are vulnerable to virus infections and other attacks, it is considered good practice to implement network access control for such computers. This practice is driven by the rise of computer viruses, privacy issues and general need for network security. The access control is enforced by a firewall, which can be a standalone hardware device or implemented as software.
Firewalls protect a computer against dangers on the Internet. Firewalls monitor or “police” all packets that are sent from or to the protected computer(s) and filter out those portions of packets that violate the applicable firewalling policy. Most commonly such policy is set to allow all packets (also referred to as “traffic”) to be sent from the computers to the Internet, but only permit return traffic to the computer that is related to packets previously sent out. This process is known as stateful firewalling as the firewall is required to remember the state of the computer(s) activities to determine if traffic is permitted to reach the computer.
Firewalls may present obstacles in Internet communications. Computers protected by a firewall may be difficult to communicate with from outside the firewall even when such accessibility is desired by the protected computer. In order for the computer behind a typically configured stateful firewall to accept a connection from an outside computer (for example, to act as a server), the firewall configuration needs to be adjusted for that particular computer. This can be a major inconvenience if there are several computers protected by the firewall and their need to establish communications outside the firewall change frequently.
Given the above, NAT devices, firewalls and other such policing devices (sometimes referred to herein generally as “traffic policing devices”) may restrict network connectivity in circumstances where such connectivity is desired. Working around these restrictions requires reconfiguration of the traffic policing device on an “as needed” basis, which is frequently not a viable option.
A virtual private network (“VPN”) is a secure virtual (as opposed to physical) network. The IP addresses used in a VPN may be independent from those used for Internet communications. Virtual private networks are used to create a private communication environment for computers that may not be in the same physical location. A VPN setup typically uses existing public network infrastructure, such as the Internet, for carrying data between VPN members. For example, VPNs can be used for building a large intra-company network that spans multiple offices. Computers within a VPN are referred to as “members.” The configuration of a VPN can be very complex and time consuming and may require superior knowledge of networking and security.
A VPN used in association with NAT can present particular difficulties. The protocols used to implement VPNs include IPsec protocols, various tunnelling protocols (L2TP, PPP and others) and application level protocols like SSL and SSH. Early versions of IPsec protocols did not work with NAT at all, but recent extensions, while usable with NAT, lack flexibility and are typically difficult to setup.
VPN connections (also known as tunnels) cannot be established towards a computer using a NAT device without explicit re-configuration; they can only be initiated by such computers. Such tunnels also cannot be established between two computers, each using a NAT device unless at least one of the NAT devices is configured explicitly for this purpose.
There are several techniques available to overcome the above-described problems. For example, external access to a computer residing behind a NAT device may be provided by using port forwarding. This requires the NAT device be configured to associate a particular Internet IP address and/or port number with a specific internal computer. All traffic that the NAT device receives from the Internet for this IP address/port is then forwarded to the specific internal computer. There are two drawbacks to this approach, namely that it is technically complex; and not all types of traffic can traverse a NAT device in this manner.
An alternative solution is known as UDP hole punching, which works as follows. An internal computer (A) sends out an initial UDP packet to an Internet computer (S). As the packet traverses the NAT device, its source port and/or IP address are modified. Computer S notes these modified IP and port numbers and sends them to the peer of A, namely computer (B), which may also reside behind its own NAT device. Computer B goes through the same procedure. In this way, both A and B learn external (i.e., post-NAT, Internet-facing) IP/port numbers of each other, and they try to communicate to each other via these IP addresses and ports. The process of sending a packet to the Internet computer is commonly referred to “hole punching” as it creates a mapping in the NAT device state and allows an internal computer to start receiving traffic from the peers outside the NAT (namely, through the hole punched in the NAT). This process is based on a number of assumptions about NAT behaviour, which often do not hold true for NAT devices. For example, NAT devices implement different strategies for selecting an external (also known as “mapped”) port when sending traffic out. Some NAT devices use different port values depending on the destination IP/port (also referred to as “non identity-preserving NAT”). Thus, the system as described above can be made to statistically work in approximately 80% of all cases where it can be applied, which results in a high failure rate.
An alternate solution in the art is to cause the internal computer to establish communications with an Internet computer, which then can relay traffic between internal computers that are in communication with it. This approach has two major drawbacks; it introduces latency in the communications; and it results in substantial bandwidth expense at the relay Internet computer.
There are still other ways of solving the VPN and NAT problem. One is use ad-hoc VPN systems that are limited to setting up tunnels towards computers not using a NAT device. This solution means that a computer cannot establish the tunnel towards a computer using a NAT device but must wait for that computer to initiate the tunnel. Another approach is a NAT having a VPN pass-through option, which allows one internal computer using the NAT device to receive VPN connections from outside. Still another approach is a centrally-managed VPN system that may include VPN management software that establishes and maintains connections to all VPN members and can command such members to perform certain actions. In particular, the management software can instruct a VPN member using a NAT device to initiate a tunnel towards another member when the latter requires it. This resolves the problem of ad-hoc VPNs, but it does not address tunnelling between two computers, both using NAT devices. In another approach, centrally-managed relayed VPN systems may include a software component known as a concentrator, which maintains tunnels to VPN members and may forward traffic to computers using the tunnels. This solution solves the problem of connecting two computers that are each using NAT devices, however, two drawbacks to this approach include extra latency and substantial bandwidth expense for the concentrator.
There remains a need to address these and other problems of the prior art.